The growth in popularity of mobile applications distributed by means of vendor distribution platforms, such as for example Google Play, Apple App Store, etc., which distribute software applications for use on mobile devices comprising a mobile operating system, such as Android and iOS, is attracting the attention of hackers. These hackers, for example in an effort to distribute unauthorized rebranded variants of the distributed mobile application try to get access to the source code, assets, resources, etc. of the distributed software application. These approaches often involve free tools and often can be performed within for example a few hours or less. This then allows the hacker, for example by means of minor modifications to resources to rebrand the software application for unauthorised redistribution. Such operations could for example include modification of resources such as the application launch icon, application logo or other images, the application name, references to urls, etc.
Java software applications offer an efficient framework for developing and deploying enterprise and server or client-side applications. During a build operation of the development stage of the software application the Java source code is compiled to Java bytecode. In this way for example there is compiled one or more Java class files, which are files, often with a .class filename extension, comprising Java bytecode that can be executed on the Java Virtual Machine or JVM. Such a Java class file is produced by a Java compiler from Java programming language source files, which are files, often a .java extension, comprising the source code programming instructions for Java classes. If a Java source file comprises more than one Java class, each Java class is typically compiled into a separate Java class file comprising its bytecode. After compilation, the build operation continues by packaging these Java class files together with related metadata and application resources, such as for example an image file comprising the application icon, in a software package for distribution. Low-cost, widely available applications are available which for example enable inspection of these software packages, to enable modification of the application resources and automatic decompilation of the Java class files into near-original source code. Attackers can then efficiently apply modifications it to implement hacks or create counterfeits for redistribution as an unauthorized or compromised version of the original application and for example resulting in a security risk and unauthorized copying of the application. Such Java applications are also being used in the context of mobile software applications, for example mobile software applications suitable for the Android operating system. In such a context Java source code of the mobile application is for example compiled to Dalvik bytecode and stored in .dex or Dalvik Executable files and/or .odex or Optimized Dalvik EXecutable files. This Dalvik bytecode can for example be subsequently executed by a Dalvik Virtual Machine, or alternatively be further compiled to native code on the mobile device by the Android Runtime or ART. During the build operation the application code, in the form of the Dalvik bytecode, for example in the form of one or more .dex files, is packaged together with further application items, such as for example resources, assets, certificates, a manifest file, etc. into an Android application package or APK for further distribution. Similarly as explained above tools are available to inspect the contents of such software packages, decompile its bytecode and enable efficient modification of application items such as for example application icons, logo's, etc., thereby leading to security risks and unauthorized copying of the application.
In order to provide compatibility with different configurations, resources of such Android applications, such as images, video files, audio files and strings from the source code of the application, are maintained independently from the source code and are grouped by type and configuration. Default resources are those that should be used regardless of the device configuration, and alternative resources are those that are designed for use in a specific configuration. It is clear that such externalised resources are susceptible to modification by means of a hacker. Such hacker can efficiently create an unauthorized, rebranded copy such an application by merely modifying or replacing the resources such as the image for the related icon, images with company logos, and other related resources used for the presentation of the application on the mobile device. Additionally the hacker might efficiently modify the decompiled source code in order to modify for example references to the web server of the original application developer to new references to of a different web server managed by the hacker.
ProGuard, available at http://proguard.sourceforge.net/, is a known software application for use during a build operation, which obfuscates Java source code by for example renaming the classes, fields, and methods using short meaningless names. An alternative known software application for use during the build operation is DexGuard available at http://www.guardsquare.com/dexguard. Dexguard focuses on the protection of mobile software applications, with additional features such as for example resource obfuscation, string encryption, class encryption, and executable application file splitting. DexGuard is focused on Android applications and directly creates Dalvik bytecode during the Android build operation in which Android programs are compiled into .dex or Dalvik Executable files, which are in turn packaged into a single software package or .apk file. Such source code or resource obfuscation increases the difficulty for a hacker to analyse the software code or to efficiently identify standard resources such as for example the application icon image. Such known Java obfuscators, during the build operation, make use of renaming of classes, fields, methods, etc., which increases the difficulty for reverse engineering the decompiled source code.
Additionally, more sophisticated applications such as DexGuard, also provide for renaming of application resource identifiers, such as the application resource file name, and corresponding obfuscated references in the corresponding source code. This increases the difficulty for efficiently rebranding such a software application by acting on the application resources. In order to still further increase the hurdle for hackers to interfere with the application source code and/or the application resources, encryption can be used. However, such encryption often relies on a standard encryption algorithm provided by applications such as for example DexGuard during the build operation and require use and distribution of standard security keys along with the packaged application in order to allow for subsequent decryption during execution of the software package on the mobile device. This provides the risk that hackers can scan for detectable encryption signatures and/or security keys, which allows them to develop a dedicated decryption application that allows decryption of all software applications obfuscated and encrypted by a particular obfuscation tool, such as DexGuard.
Still further known build systems and methods of operating such a build system are for example known from WO2011/057393 A1 of IRDETO CANADA CORP. The latter build system makes use of a plug-in mechanism to add and extend security capability and new protection. However, the distributed application comprises a Java bytecode protection security module which automatically decrypts the java application bytecode during execution. This know system further makes use of a Java application bytecode stub in order to access these protected data files and a white box security module utility. It is clear that, although this system provides for a plug-in mechanism, still, each of the above mentioned individual components could lead to the risk of detectable patterns or anchor points for an attacker with access to the distributed application, this is especially true for the protected application bytecode stub. It is further also clear that this build system is only able to increase the security level of the original application bytecode. Other items which are distributed such as for example application resources or application assets or other data items such as image data representative of icons or company logo's, databases, etc. are not handled by the Java Bytecode Protection Tool and thus remain accessible in a relatively easy way to an attacker with access to the distributed application. Still a further known build system which makes use of a combination of static watermarking and authentication method to determine whether the code has been modified and obfuscated symbolic names to increase security against modifications by unauthorized attackers is known from WO2004/023313 A1 (FRAUNHOFER CRCG). Similar as stated above the protection is limited to the class files of the mobile code, while application resources, etc. remain prone to an attack. Further the class loader, the static watermarking, the first and second associations which are processed by the class loader to resolve the obfuscated names, all could lead to detectable patterns for an attacker. Finally a further known build system is known from WO99/41651 (NATIONAL COMPUTER BOARD). This system involves encrypting bytecode for an application and encoding the decryption key in the encrypted bytecode. During run-time a code loader is executed which loads this decryption key and executes the decryption algorithm on the encrypted code. It is clear that the distributed code loader, decryption key, decryption algorithm, etc. could all lead to the risk of a detectable pattern for an attacker. Similarly as explained above also here only application bytecode is provided with an increased level of protection. Other items such as application resources, application assets, or other data items remain more easily accessible.
Therefor there still exists a need for an improved build system that is able to provide an increased level of resistance to hacking, by reducing the risk of identifiable patterns in the distributed application. There also remains a need for increasing the level of resistance to hacking for other application items than the application code, such as for example resources comprising data representative of text, images, audio, etc. of a distributed software package.
It is thus an objective of the present invention to disclose a system and method that overcomes the above identified shortcomings of the prior art. More particularly, it is an objective to disclose a system and method that, in an efficient, simple and flexible way, increases the level of resistance against unauthorised access to and modification of a distributed software package, especially with respect to resources other than the application code of mobile applications.